Subject: Response to Frank B.: Multiscast Proposal

From: David Bryant/HQ/3Com <[email-masked]>
Date: 12 Jul 96 14:44:56 EDT

Frank - 

Can't say I agree with your statements about contradictions.   Ambiguities 
perhaps, but I don't believe the document contradicts itself.  If there are 
contradictions, I'd  rather deal with them on a case by case basis.  That is, 
if there are specific sentences that are in strict contradiction, let's 
identify them, make a choice, and correct them.

I added the "Unicast and UDP datagrams in Lieu of IP Multicast" because  it 
seemed to me to be much easier than to try and reconcile the text from your 
proposal with the document.  

All that aside, I think, however, that we're having problems with mixed 
objectives.  Over time, we have begun to shift all about on what we're trying 
to accomplish.  The original proposal was to the DLSw Scalability SIG as a 
general solution to some of the scalability problems.  The goal was to increase 
DLSw scalability.  For this reason, implementation of single TCP connection was 
required. But over time, other things are creeping in like UDP unicast for any 
packet.  At the same time, there's something called "DLSw version 2" which is 
supposed to be a follow-on to RFC 1795.   The content of DLSw Ver 2 has not yet 
been defined.   I would hope that it contains the scalability enhancements 
defined by the scalability sig.  But I'm not convinced that UDP of any packet 
type is directly related to scalability in any way.  

In the meantime, I find myself thrashing a bit at the whims of scalability 
sig.  At first, everyone wanted all kinds of detail on exactly how to use 
multicast groups and addresses and peers.  Later, I was asked to remove it from 
the document.  Then people wanted detail on how to use UDP unicast, when 
unicast vs. mcast, etc.  Now I'm hearing arguments in favor of fewer rules, 
greater flexibility, and every implementer to himself. 

Before investing effort in any direction, I'd like to get some input for the 
others in the SIG regarding the UDP unicast issue, specification vs. ambiguity, 
goals and content of this effort, and any other issues with the document.

Regards, Dave

 ----- Previous Message ---------------------------------------------------- 

To: aiw-siglets-dlsw-redist  @ 3mail.3com.com @ UGATE
cc:  
From: fbordona @ cisco.com (Frank Bordonaro) @ UGATE    
Date: Friday  July 12, 1996 03:22 PM
Subject: Re: New Multicast Proposal
------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------
Dave,

I have a strong concern regarding the references to using unicast in 
place of a multicast mechanism in the current proposal. In my opinion,
there are too many contractdictions in the current proposal regarding
when it is acceptable/recomended to send via UDP unicast.

The current multicast proposal contains a section entitle
"Unicast and UDP Datagrams in Lieu of IP Multicast". This section states
that "it is possible for implementations to simply make use of the UDP
transport mechanism described in this paper without making direct use of
the IP multicast function".

This is exactly the type of flexibilty that is behind my push for the addition
of unicast-only support, but this section is not enough. The current multicast 
proposal contains "shoulds" and "musts" throughout that discourage/prohibit use
of unicasting when multicast "should/must" be used. 

In my opinion, we need to be more flexible and allow implementations 
to send any frame via UDP unicast.  There are too many ways an 
implementation can optimze traffic flow if it had this flexibility. For
example, there are cases when a CanUReach_Ex/NAME_QUERY_ex should only be 
sent to a subset of DLSw peer nodes for optimal scalability. This behavior 
should be allowed and encouraged. As it reads in the NetBIOS section of the
proposal, the table and note 2 in particular states that NAME_QUERY_ex
"should always be multicast on the WAN".

I am not sure how to interpret these contradictions. Are we trying to 
encorporate the support for sending of any  frame via UDP unicast?

It seems to me we have 2 choices.

1) Clean up contradictions in the current proposal to explicity allow
   the sending of any packet UDP unicast. In this case, the unicast 
   proposal can go away.

2) Clean up contradictions in the current proposal to explicity disallow
   the sending of certain packets UDP unicast. If this route is chosen, I 
   would like to see the Unicast proposal I posted on April 11 be integrated
   as a sub-chapter in the DLSw Version 2 Scalability Document.

Before reading the current proposal, I thought we were going with option 2,
but since the current multicast proposal tosses around the use of unicast
in lieu of multicast, it may be easier for us as a group to work on one
proposal and make it satisfy all requirements.

Regards,
Frank Bordonaro
cisco Systems, Inc.